What I Wish I Knew When I Started My Career as a 
Software Developer 
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When you're starting your career in any field, you probably have high hopes but don't really know what 
to expect. Should you keep your head down and do what you're told or should you aim only for 
ambitious projects? Here's what I've learned in my experience as a software developer. 

Let me bat out a few suggestions based on my experience and observations. This list is not all- 
inclusive — because it can't be. Your experience will be unique. 

1. Don't be afraid to learn on the job. Sadly, bookshelves at most workplaces are mostly just set- 
dressing (look at what our hackers claim to read!). You rarely see anyone reading one, especially not 
during core work hours. Still, you have a computer and can read papers and most books through an e- 
reader So get to it. You're not going to learn much if you just do what you're assigned and little more. 
You also won't move forward if you ask for more work and get grunt work. Be willing to slow down and 
do things right and read up on the fundamentals. How do people develop an expertise in a coveted 
domain like machine learning? One day at a time. 

2. Manage your career aggressively. Take responsibility for your own education and progress. 

One out often people (if that) find a mentor who will clear paths and pull strings and make sure they 
come out on top for promotions and plum projects. If you're in that other nine, and you will be most of 
the time, no one's looking out for you. So look out for yourself. Don't ask for more work unless you trust 
that person to give you better work than you'd get otherwise. When you can, do the bare minimum 
amount of work that's not advancing your career or teaching you something; if it has no career-adding 
value, people probably don't care enough about it for it to matter that you're putting in a minimum effort, 
as long as you don't get in anyone's way. After three years, if you're not being groomed for something 
bigger and badder, external promotion (read: changing jobs) is usually the way to go. 

3. Recognize under-performance and over-performance and avoid them. 

There are a lot of low-effort players who stay employed for years. This isn't a bad strategy if you're 
settled, but I wouldn't fall too low. That said, the only people who typically get fired for under- 
performance are the people who fail so badly that they generate work for others. People who hide and 
do little tend not to make any enemies. At the same time, be cautious of over-performance. This isn't 
like college where challenging your professor's ideas could earn you an 'A' if you argued your point 
well. Over-performers often generate extra work for their superiors and colleagues and draw unwanted 
attention (see: McNulty in The Wire) and are more likely to be culled for "performance" (98 percent of 
"performance management" in companies is politics) than under-performers. I'm not saying that you 
shouldn't work hard and do a good job and learn as much as you can. That's not necessarily over- 
performance; in my experience, though, over-performance — being recklessly ambitious, perhaps — is 
much more dangerous than under-performance. It can get you just as fired and it will happen a lot 
faster. If you end up stuck between the two, ebb towards under-performance. 

4. Never ask for permission unless it would be reckless not to. 

Want to spend a week investigating something on your own initiative? Don't ask for permission. You 
won't get it. You might not actually be doing your boss a favor when you ask for permission; from their 
perspective, you're asking for the right to pass the buck if your project doesn't pan out. Since he can 
deny you and your buck-passing after-the-fact, in any case, because he outranks you, you don't really 
gain anything from such a promise you might extract in the first place. So there's no upside in asking 
for that permission. Of course, if you're going to do something that presents a real risk to the business 



or where his permission would be reasonably expected, then go ahead and ask for permission. If the 
loss is small and the risk is appropriate to your level in the company (and any programming job where 
you're not trusted with days to weeks of your own time is not worth having) then don't ask for 
permission. Just do it, and do it well. 

5. Never apologize for being autonomous or using your own time. 

You can admit that a project or investigation didn't pan out, although it's best if you can spin it as a 
discovery exercise, but you should never apologize for a failed side project. It sets a precedent of you 
as a subordinate who needs more supervision. After describing something you did of your own 
initiative, don't say to the boss, "Don't worry, I did it strictly as a weekend project." If your company 
won't let you work on something during normal work hours, then don't do it on their behalf for any 
reason. Respect your time. Or no one else will. 

6. Learn CS666 (what I call the politics of software development) and you can usually forget 
about it. Refuse to learn it, and it'll be with you forever. 

As we get older, we tend to see the value in transferable and general skills: functional programming 
rather than Spring/Hibernate; algorithms rather than quirks of a Java 1 .4 legacy system. Well, CS666 
ain't pretty, but it's transferable across the industry in a way that no programming language ever will be. 
I'm not saying that one should become a political animal or get obsessed with the politics, because that 
won't end well, but one ought to be politically aware because there's politics in everything we do. It's 
good to start studying people and their moves early, even if you're not planning to play (and when 
you're young, you shouldn't play often). Whether you get the Hadoop cluster in time, who gets to make 
the technical decisions, whether you get that feature freeze you've been asking for so you can clear 
away some technical debt, and what projects you're assigned... all politics, man. For better or worse. 
Meritocracy is the software engineer's Prince Charming and, in the real world you'd best be on the side 
that gets to define "merit" and structure how it is measured. If you learn CS666, you get some time to 
breathe and forget about it and just do great work. If you don't learn it, your career will be shaped by 
those who are better at it. 

7. Don't be quixotic and try to prove your bosses wrong. When young engineers feel that their 
ideas are better than those of their superiors but find a lack of support, they often double down and 
throw in a lot of hours. "Let's prove our bosses wrong... by sacrificing our own time on somettiing they 
will own!" Sorry, but if you have to throw down weekends (except on a rare occasion, like a production 
emergency) to bring a project through, that means that your bosses don't actually care that much about 
it. Otherwise, you'd have the time and resources and no patience for quixotry in yourself or others. 
Rather than trying to hit a home run with a cracked bat, you just should just let that game be. When 
bosses are "shown up" by people they doubted, they don't give that person an automatic promotion or 
raise. They find a way to confirm their negative impression (and your earnest self-association with a 
disliked project has put some stink on you) and, even if you succeed, you fail. If nothing else, there's 
always "He did a great job on that, but he was distracted from his assigned work and so I can't trust 
him going forward/we can't let him set a precedent/it was actually my idea." 

8. Don't fight other peoples' battles. As you're young and inexperienced, you probably don't have 
any real power in most cases. Your intelligence doesn't automatically give you credibility. If you get 
involved in someone else's fight, or stand up for someone being unjustly treated, you'll just get mowed 
down. Watch Mad Men and The Wire and Breaking Bad for how people really are when there are any 
stakes. Save all your energy for your own fights. The corporate world is not a place where social justice 
is valued — people protest by leaving, not picketing — and you won't make any friends as a crusader. If 
you fight for yourself and it ends badly, you at least get some respect from some people (and that may 
pay off, years down the line) for your self-preservation. If you fight for other people, you're seen as an 
arrogant young fuck who didn't know the rules. 

9. Try to avoid thinking in terms of "good" versus "bad." Be ready to play it either way. Young 



people, especially in technology, tend to fall into those traps — labeling something like a job or a 
company "good" or "bad" and thus reacting emotionally and sub-optimally. You might think something 
like: 

"I'm not going to work hard because my boss yelled at Sam today and I'm upset" or "I'm going to 
sacrifice my own health and career goals and throw 90 hours per week after grunt work because this is 
a great start-up and we're changing the world." 

Yeah, fuck that. Every organization is a mix of good and bad. Whatever the territory, use it to your 
advantage. Boss yells a lot? That actually makes him less of a threat to your career, should he go 
against you, because they probably aren't trusted by their own superiors either. Assigned a boring 
project? It's probably boring to your managers too, which means they won't look at you much. You can 
put in a few hours per week and have 30-40+ left over to learn skills for your next job. Fucked-up 
culture? If you can stand it and others can't, you're a valued employee — and you can treat it as a 
learning opportunity ("MBA by counterexample"). It's important to stop thinking of every event as 
"good" or "bad" in some biblical sense and just see the angles and how to play it. This is a skill that 
seems to improve greatly with age. You stop sizing complex entities like corporations as "good" or 
"evil" and just learn how the play the landscape as it is. 

10. Never step back on the salary scale except to be a founder. As a corollary, if you step back, 
expect to be treated as a founder. A 10% drop is permissible if you're changing industries (out of 
finance and into biotech research) or moving to a lower cost-of-living area. Beyond that, the answer is 
"no" unless you're making a permanent move. Most people are actually really bad at assessing how 
good someone is at his or her job, which means that, in the private sector, your salary is the best 
assessment of your global rank and is a starting point for future negotiations. You better have a damn 
good reason if you step back, and it better be a high-status one. 

Employee positions at start-ups are no exception (count the equity at zero, for the purpose of this item). 
If you leave a $1 50,000 per year hedge fund job for $90,000 "plus equity" (like, what? 0.05 percent?) 
then, congratulations, you're now a $90,000/year programmer. That's actually quite fine (being a $90k 
programmer) if you've moved to a less expensive area and intend to stay there, and it's fine if the 
company is arguably idealistic (e.g. clean energy) because you can probably bounce back to where 
you were if you're a good negotiator, but if you took that drop for other unjustifiable reasons, then you're 
just a chump and, no, you're not changing the world by fixing bugs in ad servers. 

11. Exercise. 

It affects your health, your self-confidence, your sex life, your poise and your career. That hour of 
exercise pays itself off in increased productivity. If you find yourself no longer exercising, you're 
throwing down too many hours and you need to garbage-collect your life. 

12. Long hours: sometimes okay, usually harmful. 

The difference between 12% growth and 6% growth is meaningful. Applied to a $60,000 salary over 10 
years, one takes you to $107,451 and the other takes you to $186,351. That's a big difference (not just 
in salary, but in the level of job that those numbers suggest). When your work is multiplicative in nature 
and your input/output relationship is truly exponential, work hard. Don't work long hours on the merely 
additive stuff ("more of the same") that doesn't advance your career or knowledge in a long-standing 
way. If you're just doubling up on grunt work so some jerk boss can save money because you're 
working two positions and taking one salary, then fuck it. Walk away. It may not feel like the case, but 
he needs you more than you need him. 

13. Recognize core technological trends apart from fluff. 

Half of the "NoSQL" databases and "big data" technologies that are hot buzzwords won't be around in 
1 5 years. On the other hand, a thorough working knowledge of linear algebra (and a lack of fear with 



respect to the topic!) will always suit you well. There's a lot of nonsense in "data science" but there is 
some meat to it. Likewise, there's a lot of puffery and goofiness in "NoSQL" but non-relational 
databases do have their place. It's your job (and you get better at this over time, but start making 
guesses when you're young) to figure out what are core technological principles that make sense and 
are worth learning for the long term (e.g. functional programming) and which are just fads. It's often 
useful to have fluency in the fads (for example, if you need a job right now) but you shouldn't spend too 
much time on them. Buzzword-compliant programmers with weak fundamentals get stuck writing glue 
code and having to learn new junk when their old junky knowledge goes out of style. 

14. Finally, learn as much as you can. It's hard. It takes work. This is probably redundant with some 
of the other points, but once you've learned enough politics to stay afloat, it's important to level up 
technically. And, when you're out of school and probably not going back, it's hard. Even the really smart 
people find it hard to read the cutting-edge papers. (In part, that's because many papers aren't well- 
written, but that's another topic.) No one is born with the ability to look at complex equations and just 
intuit what they mean. That stuff took the smartest people in the world hundreds of years to discover 
and, once discovered, it's much easier for the rest of us to follow along... but it's not without difficulty. If 
you want to be a great programmer, you'll probably have to study as an adult (with no grades!) harder 
than 95% of college students (and, maybe, 65% of graduate students) actually do study. 

This answer has been edited for grammar and clarity. 



